1. Field of the Invention
The present invention relates to displays, and more specifically to a method for correcting flicker and flutter effects of an on-screen display overlaid on a video image by assigning new values to the pixels of certain lines of the on-screen display based on the neighboring pixels of the video image.
2. Description of Related Art
A video image is formed by a sequence of lines of pixels. The pixels are elementary picture elements. In color television systems, each pixel is a carrier of luminance information and chrominance information that makes it possible to specify the luminosity and color of each image point. In the most commonly used television systems, the image develops according to a principle of horizontal scanning of the screen. Whether it is the NTSC television system, the PAL television system, or the SECAM television system, each image displayed results from the alternating display of two distinct partial images known as frames. In general, there is a first frame, which is known as an odd-parity frame, and a second frame which is known as an even-parity frame.
The very nature of television images (i.e., the interlacing of two partial images) gives rise to problems of image quality and flicker. In an extreme case, a line of black pixels on a white image background gives the human eye the unpleasant impression of appearing and disappearing, especially if this line is observed from a close distance. Furthermore, it is increasingly common to present on-screen displays (OSDs) that are overlaid on video images. Each pixel of an OSD is characterized by three values Y, U, and V that detennine luminosity and color and a value MW for transparency. For example, OSDs are commonly used to provide a permanent or non-permanent indication of the progress of a sporting event, such as the score of a match. OSDs are also used by certain television channels to show their logo so as to indicate to the viewer the television channel that is being watched.
FIG. 1 shows a conventional structure for the code of an OSD. A binary train 10 containing the codes needed to display an OSD typically consists of three sets of bits that have different functions. A first set of bits 12 forms the OSD header. The OSD header 12 has information on the number of bits needed to define a pixel, and information on the coordinates of certain characteristic points of the OSD. A second set of bits 14 is used to define the panel of colors that will be used during the display of the OSD. All of the colors that will be used are stored in a memory known as a color look-up table (CLUT).
Generally, the CLUT is limited to 256 memory lines, with each memory line containing the values of the bits corresponding to a color programmed in a table through the second set of bits 14. The choice of the size of the color look-up table results from a compromise between the access speed of the table and the number of colors needed to provided accurate quality for the OSD. Additionally, a third set of bits 16 is formed by the addresses of the memory lines of the table of the available colors containing the appropriate color for each pixel of the OSD.
While flicker problems exist, in purely analog television pictures they are small as compared with the flicker phenomena that can appear when digital on-screen displays are presented on a video image background. In particular, the systematic attenuation of contrasts in video images, which is caused by the presence of cameras in the image generation cycle, is not encountered during the creation of an OSD. As a result, two patterns of colors that are distant from each other in the spectrum of visible frequencies may be juxtaposed. Thus, major contrasts may appear between two consecutive lines when digital on-screen displays are overlaid on the video image. Further, when an OSD is created, the background of the video image on which the OSD will be displayed is not generally known. Thus, in extreme cases, a blue OSD may be displayed when the background of the video image is red. Additionally, nothing prevents the designer of an OSD from juxtaposing two lines with high contrast with respect to each other in the OSD itself.
FIGS. 2a and 2b illustrate problems that can be encountered during the display of an OSD on a video image background. FIG. 2a shows a television screen 10 that is displaying an OSD 21 on a video image background 20. The OSD 21 shows a zone with a white background from which there emerges a thin black line with the width of a pixel. This is typically the case where the flicker effect is the most visible. Due to the interlacing of the even-parity and odd-parity frames, the thin black line 22 appears and disappears at a speed that is low enough for this phenomenon to be detected by the human eye.
FIG. 2b shows another problem related to the display of an OSD on a video image background. On the background of a video image 20, an OSD 21 is formed by a first pattern 24 that is displayed with the even-parity frame and a second pattern 25 that is displayed with the odd-parity frame. This gives an impression of flutter 26. More specifically, the OSD seems to rise and fall the amplitude of a pixel at a rate dictated by the refresh frequency of the frames of the image. This flutter problem has the same cause as the flicker problem. The phenomenon of flutter appears when the same image is displayed by the even-parity frame and by the odd-parity frame. Depending on the television system used, the even-parity frame appears every 1/25 seconds or every 1/30 seconds in alternation with the odd-parity frame. The human eye detects a flutter motion due to the appearance of the OSD alternately on one set of lines and then on the set of directly neighboring lines.
These phenomena of flicker and flutter are mainly perceived when long horizontal lines are displayed on the screen, which is frequent in OSDs. There are several conventional approaches to overcoming these problems of vertical transition in the definition of an image having one or more OSDs. For example, it is possible to act on the transparency of the pixel of an OSD. This approach is applied to the lines or groups of lines that constitute the borderline zone between an OSD and a video image. To avoid the sudden transitions of color that give rise to the phenomena explained above, it is also possible to apply mathematical filters that use the values of neighboring pixels and weighting to compute new values of these pixels.
The use of one such mathematical filter will now be explained. For a current line of pixels of an OSD to be processed, the values of the pixels of the neighboring lines are taken into account to determine new values for the pixels of the current line. For example, for a current line n of odd-parity frame I, the lines n and n-1 of the even-parity frame are taken into account. More specifically, for each pixel k of the current line of the OSD to be displayed in column i of the screen, the new values I.sub.i *(n) of pixel k are computed from: (1) values P.sub.i (n) and P.sub.i (n-1) of the pixels of lines n and n-1 of the even-parity frame P of the OSD to be displayed in column i of the screen; and (2) old values I.sub.i (n) of the pixel k of the current line.
In this example, the new values I.sub.i *(n) are obtained according to the following equation. EQU I.sub.i *(n)=a.times.P.sub.i (n-1)+b.times.I.sub.i (n)+c.times.P.sub.i (n) (1)
where a, b, and c are weighting coefficients. The weighting coefficients are specific by their number and value to each mathematical filter. Their value ranges from 0 to 1 and the sum of all the weighting coefficients must be equal to 1. In this example, only the two pixel lines adjacent to the line of pixels being processed are considered. The new values I.sub.i *(n) provide a line of pixels that does not have excessive contrast with the neighboring lines, and thus the risks of flicker and flutter within the OSD are diminished. Although the mathematical filters associated with equation (1) are generally quite efficient, it is also possible to apply mathematical filters that bring more than three lines of pixels into the computation.
While such mathematical filters are efficient within the OSDs, they cannot be applied to the lines of the OSD that constitute the boundary between the OSD and the original video image. This is because the values of the pixels of the video lines other than those of the current line are not available because they are not preserved in the memory. Thus, the filter associated with the equation (1) cannot be applied. That is, the values P.sub.i (n-1) are not available because they are the values of the pixels of an already displayed line of an original video image.
Similarly, a mathematical filter that, for current line n in each column i of the even-parity frame P, assigns the pixels the new values P.sub.i *(n) according to equation (2) below cannot be applied to a line of an OSD that precedes a line of an original video image. In particular, the values I.sub.i (n+1) correspond to the line following the current line and are not available in any memory. EQU P.sub.i *(n)=a.times.I.sub.i (n)+b.times.I.sub.i (n)+c.times.P.sub.i (n+1) (2)
Thus, when the line of pixels of the OSD being processed is a line marking the boundary between the OSD and the original video image, no account is taken of the values of the pixels of the lines directly adjacent to the current line. In other words, equations (1) and (2) become equations (3) and (4), respectively.
I.sub.i *(n)=a.times.I.sub.i (n)+b.times.P.sub.i (n) (3) EQU P.sub.i *(n)=a.times.I.sub.i (n)+b.times.P.sub.i (n) (4)
Consequently, if the lines of pixels of the original image directly adjacent to the OSD have a high contrast with the boundary lines of the OSD, the phenomena of flutter and flicker will still be present. In particular, the lines of pixels of the original video image do not play a role in the computation so no contrast attenuation is achieved with respect to the lines of the original video image. Furthermore, the impossibility of using the efficient mathematical filters associated with equations (1) and (2) for all the lines of the OSD necessitates the use of either less efficient filters for all the lines to be processed or different filters that are each adapted to the OSD line to be processed. This approach is complex to manage and requires a greater programming memory.